This should fix i386 test failures such as this one:
https://buildd.debian.org/status/fetch.php?pkg=openblas&arch=i386&ver=0.3.33%2Bds-1&stamp=1777066182&raw=0
Last-Update: 2026-05-16
Gbp-Pq: Name trsm-barcelona.patch
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2026-02-03
Instead use the PIC libraries provided by packages liblapack-dev and liblapack64-dev,
stripping from them the symbols that are overridden by OpenBLAS.
Last-Update: 2026-02-03
Gbp-Pq: Name no-embedded-lapack.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
projects / openblas.git / log